1. Technical Field
The invention relates to organizing data for better efficiency at runtime. More particularly, the invention relates to a technique for organizing policy rules to efficiently evaluate protocol events at runtime.
2. Description of the Prior Art
Networked information systems are an essential part of many organizations. Critical systems, services, and information resources all require protection that depends on effective orchestration of a variety of factors: network architecture, security products, site security, administrative procedures, end user responsibility, and more. A network security policy is an explicit plan of how to accomplish this multi-faceted protection, what objectives the plans should meet, and what assets are being protected.
To manage a network, an end user needs to know and understand what is happening on the network. Most security holes come from unexpected, misconfigured, or unauthorized services, for example, from a high-port telnet, a new service added in, a rogue server, and/or a misconfigured workstation. The end user does not know what is the unauthorized network traffic.
Security administrators need tools to help them formulate site security policy and to translate the policy into monitoring and enforcement mechanisms. They need to be sure that the computer enforced policy—often cobbled together from a plethora of disjoint access control mechanisms—matches their enterprise policy, all too often specified in a loose natural language or a set of unwritten principles. This leads to confusion as to why access is being granted or denied to particular resources and may lead to unintentional breaches of security.
In addition to monitoring network system traffic, it is important for network analysts to assess their network's configuration. A discussion on current techniques for network assessment follows below.
A conventional network assessment visit determines the customer network using the following information:
1) Network security scanning technology, e.g. port or vulnerability scans;
2) Customer interviews;
3) Inspection of customer log files, perhaps using machine aggregation and filtering; and
4) Occasionally, inspection of customer log files and network traffic.
As a matter of practicality, the information is typically derived from the first three of these items. Customer log files and network traffic is of a volume so great that it is impractical to examine it in a short assessment visit.
The weaknesses such conventional methods are as follows:
Vulnerability Scans
Network vulnerability scanners only detect certain types of known vulnerabilities. Such vulnerabilities are generally not detected directly, but are inferred based on host responses to a series of network packets sent to hosts by the scanner. This process does not directly ensure that data traffic on the subject network matches expectations, either explicit or implicit.
Network vulnerability scanners cannot see a host if it does not respond to packets. A host that is only a source of network packets, such as, for example, a rogue router, is not visible to a scanner. Hosts which are turned off or otherwise temporarily disconnected, such as, for example, workstations and laptops, are often missed by vulnerability scanners. This problem is compounded by the fact that scans are often scheduled for non-work hours in order to alleviate customer fears that the scans will somehow impact production systems and organizational mission.
Network scanners typically return a large volume of vulnerability information, based on all possible configured elements in a network. The scanner tools cannot currently interpret those vulnerabilities in light of business requirements which the subject systems are intended to support, or even for the specific network architecture of which those systems are a part. The scan results must be reviewed manually by a security analyst, who applies a knowledge of the business requirements and network architecture to an interpretation of those results. Such manual process is error-prone because the volume is so great that problems may be overlooked.
Another problem is that the scan derives only vulnerabilities, not network usage patterns. Therefore, the scan cannot detect security problems that are attributable to human behavior, but only those scans that result from misconfigured systems and/or systems which have documented design problems.
Network scanners cannot diagnose incorrect client usage of software. For example, network scanners cannot detect whether web servers are being used with invalid ciphersuites, whether 40-bit browsers are in use, and whether a given telnet port is accessed only by a management station.
Network scanners must be targeted to particular subnets. If a customer has forgotten to mention a subnet, the scanner does not notice it.
Customer Interviews
Customers may not provide the network analyst complete or accurate information, either because the customer forgot details, because the information is not known to the customer, or because the customer does not understand the importance of giving the information to the analyst.
Customer interviews at best can provide descriptions of overt usage of subject systems, and generally not covert usage. Often, formal policies of the organization are not even documented, much less promulgated, audited and enforced.
Hidden agendas, office politics, and other factors also can affect the success of the interview process.
Host Inspection
Inspecting host configuration files is a time consuming, manual process that is subject to human error. In the assessment of any large network, it is impractical to include an inspection of the configurations for more than a few critical systems.
Once again, inspection of host configurations does not reveal completely intended usage of the subject systems. The configurations must be analyzed within the context of the business requirements and overall security environment of the organization. This manual process is very human dependent and prone to error.
Log File Inspection
Log file inspection can provide great insight into the workings of network components. Machine-based aggregation and filtering systems can speed this process. However, logs provide only a components' own view of its status. If a component is misconfigured, the log data from the component cannot be trusted. Log data may also be subject to modification by an attacker who has penetrated the machine and is seeking to mask his presence.
In addition, because log aggregation systems work in cooperation with the components that generate the information, they require configuration changes to every component that they examine. Also, they are unable to detect when a component is added to the system.
Such techniques of performing network assessments generally are limited in their ability to determine actual security threats to information systems. Generally, they represent the state of the art and are indicative of best practices within the security community today.
A way to reduce or eliminate the confusion described above is by providing a user-friendly and, yet, rigorous way of specifying security policy, as well as providing tools for monitoring and enforcing the security policy.
It would be advantageous for a network policy to provide the definition of normal traffic on the network.
It would be advantageous to provide a monitoring mechanism that lets an end user determine and understand traffic and/or activity on a network.
It would be advantageous to provide methods and system that, when given known network characteristics, thereby spots intruder access, and track changes to a network.
It would be advantageous to provide a policy generator tool that assists an end user in generating security policy for a network.
It would be advantageous to provide a tool that automatically converts a network security policy into English language representation.
It would be advantageous to provide a tool that allows an end user to query network traffic data.
It would be advantageous to provide a technique for transmitting an event description of network traffic from a source file or data stream to a target destination, such as a network policy engine.